1. Field of the Invention
The present invention relates to web servers configured to process information requests from clients in client-server type applications.
2. Description of Related Art
Current web server architecture utilizes one system to process HTTP data (both requests and responses) and Ethernet, IP, TCP, and HTTP protocols. However, such an architecture does not scale because as the packet data is passed up the stack and processed, and each level of the stack is required to parse out the data that it needs from the original packet.
Conventional computer network architecture consists of three main sections. The first of these is the client software. Common examples are Microsoft Internet Explorer™ and Netscape Mozilla™ browsers for the HTTP protocol. The client software is the interface that is used to present the data or information to the user and is therefore under the full control of the user. Normally the client software issues requests to the Web server via the neck of communication mechanism for the data that the user desires to see. However, before the HTTP session can be established, low level protocols are used to establish the communication channel thereby providing HTTP with the reliable protocol transport that it requires.
The second main section is a communication mechanism in place to provide a reliable transport of information and data between the client software and server software. Fault-tolerant protocols are used to transfer the requests and responses, normally as part of a session between the client and server software. The network is made up of a physical communication mechanism that today is constructed from either copper or fiber cables. The cables carry the signals that are generated by the network connection equipment. The network connection equipment converts the protocols in use today to the low level signals that are needed to transfer the data across the physical connection.
The third main section of network architecture is the server software. There are many examples of server software in use today; however, for HTTP, Microsoft's™ IIS Web server and the open software foundations' Apache Web™ server are the dominant solutions in use today. The application-specific server software generally resides on top of a general-purpose operating system that is capable of doing many things in a acceptable manner. However, it is generally not capable of providing the most efficient and high performance environment that would be optimal for the application. It is a trade-off between being able to do many things and being extremely efficient at a single task, or a number of smaller tasks. Because of these trade-offs, Web servers in use today are inefficient and do not provide the most cost-effective solution or even the best utilization of the computing resources that they consume.
The procedure and handshaking process is very well-defined and followed by all the vendors that make use of the Internet today, because most systems in use follow the same set of rules, and interoperability, at least at the protocol level, is assured.
With reference to FIG. 1, the client follows what is referred to as a three-way TCP (Transmission Control Protocol) handshake procedure. The client sends (at 200) a SYN packet to the glistening port on the server. The server is required to acknowledge receipt of the SYN packet and acknowledges receipt by replying (at 202) with a SYN-ACK. When the client successfully receives the SYN-ACK it acknowledges that the server is ready to accept a connection and sets up a connection on the client. When the connection is successfully initialized it will send an ACK (204) back to the server indicating to the server that the client is now ready to request data 204. Once the three-way handshake is complete and a TCP connection has been established, the connection is ready to transfer application data, which in this example is an HTTP connection. The HTTP client will now send (206) a valid HTTP request for the data that is needed by the client. The server will reply (208) with the requested data. This sequence of events will continue until the client has all the data that was requested. To terminate the connection the server sends (210) a FIN packet to the client. The client acknowledges receipt of the FIN packet and the fact that the connection with the server needs to be terminated, by replying (212) to the server with a FIN-ACK acknowledgment packet. When the server receives the FIN-ACK it will terminate the connection with the client, and it can now release all the resources that were being used for the communication to the client, and reply (214) back to the client with an acknowledgment packet.
Although the above procedure is a very simple handshaking and simple request and response mechanism that is used to transfer the data, it is possible for the client to have multiple connections to multiple servers. As a result, the servers are forced to manage each of these connections in a very reliable fashion. The server is required to maintain the status of 14 fields in the case of IP (RFC 791) and 18 fields in the case of TCP (RFC 793), for each connection. This connection management function that the server is required to perform places a significant drain on the computing resources that could have been otherwise used for data management functions.
The present invention therefore seeks to free up the computing resources of servers by facilitating connection management.